System and method for verification, authentication, and notification of transactions

ABSTRACT

A system and method for verifying, authenticating, and providing notification of a transaction, such as a commercial or financial transaction, with and/or to at least one party identified as engaging in the transaction and/or identified as having a potential interest in the transaction or type of transaction, are provided. A central system accepts information regarding a transaction, including information about at least one party identified as engaging in the transaction, such as by a credit account number or Social Security number or merchant account number, and/or identified as having a potential interest in the transaction. Based on the information regarding the transaction and any supplemental information the central system determines, the central system communicates with and/or to at least one party and/or additional or alternative parties, via at least one communications device or system having a communications address, such as a telephone number or Short Message Service address, predetermined as belonging to the at least one party and/or additional or alternative parties. Via said communications, at least one party having an interest or a potential interest in the transaction may be notified of it, and may further be enabled or required to supply additional verifying or authenticating information to the central system. If the transaction was initiated or engaged in via a communications link, such as via the Internet, said communications preferably occur over at least one different communications link and/or protocol, such as via a wireless voice network. The central system may then compute a result based on the outcomes of said communications, and may then transmit the result to the user and/or to a second system or device.

PARENT CASE TEST

This application is a continuation (CON) application of U.S. patentapplication Ser. No. 10/354,609, filed Jan. 30, 2003, entitled “Systemand Method for Verification, Authentication, and Notification of atransaction,” which claims priority to U.S. Provisional No. 60/354,275with filing date Feb. 4, 2002, both of which are incorporated herein byreference in their entireties.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to fraud prevention and fraud “early warning”notifications for transactions, in particular remote and/or electronictransactions such as “e-commerce” and “m commerce” transactions whereinit is desirable to authenticate and verify one or more parties'identities and intentions before the transaction is concluded and/or tonotify one or more parties of the occurrence of the transaction.

2. Description of the Related Art

In a transaction in which security is a concern, such as anelectronically conducted transaction involving a funds transfer or apurchase or payment, there are three basic questions which must besatisfied:

-   -   1. Are the parties to the transaction who they say they are? (Do        they own the goods, services, or funds or financial accounts        that they represent they do?)    -   2. Do they have the necessary authority or authorization to        approve the transaction?    -   3. Is the environment in which the transaction occurs secure?        That is, can other parties gain access to the private        information being exchanged during such a transaction?

Regarding question 1, the payments industry has devoted considerableattention to methods and systems designed to a) verify the identity of apurchaser, b) assess the risk of any given transaction, and c) takefollow-on action in high-risk cases, either by subsequently inquiring ofthe payer whether the transaction was proper, or by denying funds orcredit at the time of the transaction subject to later manual contactwith the payer.

For more complex or higher-value transactions, per question 2 a buyermay be subject to a set of audit and control procedures designed tolimit his/her purchasing authority. In most consumer purchasing cases,the buyer and authority-holder are usually the same person. In manyorganizational purchasing situations, the buyer(s) andauthority-holder(s) are not the same. The payments industry has oneprimary tool for limiting purchasing authority, which is the spendinglimit or credit limit associated with the buyer's account. Attemptedsolutions to question 1 also help address question 2, since verifyingidentity helps address cases wherein a buyer is suborning the purchasingauthority of another party by use of a stolen credit card number orother private information.

As regards question 3, the most relatively secure environment forpurchase transactions remains a merchant's store, in which a buyer andseller can interact face to face, multiple forms of identification canbe reviewed, and the opportunities for theft of private information aregenerally limited. At the other extreme are telephone, mail, andelectronic commerce, in which the buyer is represented merely by his/heraccount information as supplied by phone, on a mailed form, or by dataentry via a computer or other electronic device. Here, the opportunitiesfor fraud and the theft of private information are relatively high.Further, there is a prevailing public perception that electronicpurchasing environments (for example, virtual storefronts or Internetauctions) are inherently insecure in regard to the transmission and/orstorage of private information.

The above factors are reflected in the relative “discount rate” (price)charged to merchants by credit card processors for in-store transactionsvs. “card not present” transactions, for example. Typically, merchantspay 60% more per sales dollar in a “card not present” transaction thanwhen a credit card is physically presented for swiping.

These differences in risk also apply when accounts themselves areopened, closed, and modified remotely, as via mail, telephone, wire, orother electronic means.

Current transaction-verification systems and methods, such as forcredit, debit, and purchase-card purchases and payments, AutomatedTeller Machine (ATM) interactions, e-ticket redemption, and the like,may be grouped into four broad categories: 1) physical identification ofthe purchasing party or of a difficult to-mimic characteristic of thepurchasing party, such as by signature comparison or biometric scanning,2) data entry of passwords or other identification codes, such as thePersonal Identification Number (PIN) codes used with ATMs and callingcards, 3) validation of embedded digital authenticating information,such as is found in “smart cards”, and 4) verifying private knowledgepresumed known only to the account holder, such as the account holder'sbilling address or Social Security Number (SSN), prior to approving atransaction, including opening, closing, and modifying an account. Afifth category, devoted to limiting the exposure of sensitive privateinformation such as credit card numbers to insecure or weakly secureenvironments subject to high levels of electronic theft or hacking, suchas the Internet, is the substitution of dummy information for the actualprivate information, which dummy information is reconciled with theactual private information after its receipt by the payment processingorganization.

Additional systems and methods have been employed by credit reportingagencies, which agencies already monitor the status of individuals'credit accounts. Such organizations may offer their customers regularmonthly communications by mail or electronic mail identifying newaccounts established in the customer's name or with the customer'sfederal tax identification number since the last such communication.

Especially in categories (2) (3) and (4) above, transaction approval bya bank or other merchant processing or payment processing organizationor network is often coupled with an automated risk detection processesand human follow-up, as when a credit card issuer's risk assessmentsystem determines that an unexpectedly large, out-of-state purchase is“high risk” for a given account holder, and then provides thatinformation to a customer service representative who may call theaccount holder's telephone to attempt to confirm the transaction'svalidity, typically after the fact, or to leave a message for theaccount holder that the card account is suspended pending the accountholder's reply. It is often the case that the account holder's abilityto judge what constitutes a fraudulent transaction conducted in his/hername considerably exceeds that of said risk assessment system andcustomer service representative. Despite this judgment-gap, today'saccount holders have, at best, only after-the-fact means available tothem from their financial institutions, or from merchants, to audittransactions occurring in their name, including the opening, closing,and modification of accounts, or at-the-time means which involvesignificant new technologies and new processes to implement, learn, anduse. In some cases the burden of implementing, learning and using fallson the merchant or other provider of goods, services, or funds, as wellas the account holder.

Merchants subjected to fraudulent transactions are informed after thefact as well, when the true account holder disputes a transaction withhis/her payments organization. In the case of credit card transactions,the merchant is then charged back for the value of the disputedtransaction and may also be charged a dispute investigation fee,resulting in a loss of profits and goods.

Additional research and development in the payments industry has focusedon adding encrypted identifying codes or digital certificates to creditcards via an embedded microprocessor (as in “smart cards”) or viasoftware on a personal computer (“e-wallets”); and on physicallyprinting unique numeric identification numbers or numeric passwords(such as CVV2/CVC2/CID codes) on credit cards. Said codes are arelatively recent security feature for use in “card-not-present”transactions and now appear on, for example, Visa, MasterCard, AmericanExpress and Discover cards. As of this writing, these codes arecomprised of a three- or four-digit number which provides acryptographic check of the information embossed on the card, called CVV2(Visa, 3-digit), CVC2 (MasterCard, 3-digit), and CID (American Express,4-digit, and Discover, 3-digit). These code values help validate twothings: a) the customer has the physical credit card in his/herpossession, and b) the card account is legitimate. CVV2/CVC2/CID dataare printed only on the card; they are not contained in the magneticstripe information per se, nor do they appear on sales receipts orstatements. The use of these codes attempts to make it more difficultfor a person who has stolen a credit card number, but not the actualcard, to enter into fraudulent transactions, provided the other parry orparties to such transactions have also invested in the requisite changesto their systems and processes to support the use of these codes.

The prior art attempts, with mixed results, to solve the common problemof how to authenticate and verify a transaction, such as purchase, fundstransfer, account opening or closing or modification, etc., particularlywhen conducted remotely or electronically, how to authenticate andverify the relevant party or parties, and how to provide the earliestpossible warning of fraud, with a high degree of accuracy andcompleteness and near-zero delay.

U.S. Pat. No. 6,182,894 to Hackett describes systems and methods to useCVV2/CVC2/CID values, in lieu of PIN codes, to verify that a consumerengaged in a point-of-sale (POS) transaction possesses the transactioncard at the time of purchase and/or is the true card owner. TheCVV2/CVC2/CID information is provided to the POS system as an additionalauthenticating datum, and if said datum matches what is stored in therelevant authorization system for the applicable card account number,and authorizing parameters are satisfied, authorization proceeds. Ifnot, authorization is denied. Such systems and methods do not protectagainst card theft or hacking (should such CVV2/CVC2/CID data flow fromthe consumer to the merchant or card processor electronically, or arestored on an intermediate system), because they authenticate only thatcertain data from the physical card match data stored in theauthorization system, without authenticating the identity of the cardholder/user, and without verifying the intentions of the true card owneror other co-authorizing party (if different). Further, they do notprovide the advantage of notification of the true card owner or otherco-authorizing or auditing parties of the occurrence of a transaction,and in particular a high-risk transaction. Finally, such systems andmethods also fail to provide for any additional automated datagathering, authentication, and verification for and by the partyregarding the opening, closing, or modification of an account remotely.

U.S. Pat. No. 5,727,163 to Flews describes a system and method forconcluding a transaction by telephone that was initiated over theInternet. The purchaser dials a special telephone number associated withthe transaction and provides his/her credit card number in full bydialing it on his/her touch-tone keypad (that is, using DTMT tones).Such a system and method have the advantage of partially isolatingprivate payment information across two different communication links,but do not address the problem of notification or authentication of thelegitimate account holders or other parties having a potential interestin the transaction, nor verification of the intent and approval of saidlegitimate account holders or other parties having approval authorityfor the transaction. Instead, they provide assurance solely to thepurchaser that his/her private financial information need not becommunicated in full through a network perceived to be insecure (thatis, through the Internet). Such a system and method, which requirepurchasers to take additional proactive steps to complete remotetransactions, have had limited adoption by consumers and merchants dueto the complexity they add to all affected transactions. This system andmethod are further limited to collecting payment data, such as a creditcard number, for processing by the merchant's point-of-sale or orderingsystem, under the purchasing party's control. They do not provide forany additional data gathering, authentication, and verification for andby the party attempting to collect payment or open, close, or modify anaccount remotely, nor for and by any third party whose approval isnormally required to conclude the transaction.

U.S. Pat. No. 6,324,526 to D'Agostino describes a system and method forproviding a transaction code, supplied case by case by the purchaser'sfinancial institution, in lieu of a credit card number for a purchasetransaction. As has been noted, systems and methods based on dummytransaction or account number codes have had limited consumer acceptancebecause of the complexity to set up and use them. Such systems andmethods attempt to address only the security of the purchaser's accountinformation, by eliminating exposure thereof to a third party over anetwork perceived to be insecure (that is, over the Internet). Nor dosuch systems and methods provide for any additional data gathering,authentication, and verification for and by the party attempting tocollect payment or open, close, or modify an account remotely, nor forand by any third party whose approval is normally required to concludethe transaction.

U.S. Pat. No. 6,270,011 to Gottfried describes a system and method forcoupling a fingerprint recognition device to a credit card scanner. Ashas been noted, systems and methods of this type have extremely narrowapplication because of the need for the affected parties' physicalpresence, the associated cost of implementation and on-going support,and general public concerns over personal privacy when biometric devicesare employed. Systems and methods of this type attempt to address onlyauthentication of a purchaser's identity, and ignore notification of aparty or parties who may be subject to identity fraud or fraudulenttransactions.

U.S. Pat. No. 6,341,724 to Campisano describes a system and method forusing the telephone number of a credit card owner, plus a PIN code, asan alias for the actual card number in a credit card transaction. Thissystem and method replace the account number with another sequence ofdigits which is not printed or encoded on the credit card itself.Systems and methods of this type are a variation on the concept of adummy account number, per U.S. Pat. No. 6,324,526 to D'Agostino, andprovide the benefit of allowing a purchaser to make a credit cardpurchase without having to remember his/her card number. However, suchsystems and methods do not provide protection against the use of stolenaccount information, nor against the use of stolen dummy accountinformation such as said telephone number and PIN. They further requirecredit card users to learn a new process for making credit cardpurchases, and require system and rule changes by merchants to allow thepurchaser's telephone number and PIN to be used in lieu of a cardaccount number. For debit card transactions, the purchasers wouldfurther have to supply two PIN values, one for the debit card account,the other for encryption purposes. Nor do such systems and methodsprovide for any additional data gathering, authentication, andverification for and by the party attempting to collect payment or open,close, or modify an account remotely; nor for and by any third partywhose approval is normally required to conclude the transaction.

U.S. Pat. No. 6,023,682 to Checchio describes a system and method forcommunicating a credit card number to a payment-authorizing computersystem from a point-of-sale credit card terminal, using encryption wherethe key is a personal identification code (“PIC”) belonging to the cardowner, and then verifying that the personal identification code matchesthat stored in the payment-authorizing computer system's memory. Thissystem and method introduce the advantage of using personal information(such as a PIN code) to verify a card-user's identity, but also requirechanges to payment authorization systems and merchant's order-taking orpayment-processing systems to implement, further require the purchaserto supply his/her personal identification code to the merchant, and haveutility only at a physical point-of-sale, that is, in a non-remotetransaction. Because the PIC is communicated through the same processand media as the transaction itself, said personal identification code,particularly for e-commerce transactions, is vulnerable to theft viahacking of the merchant's systems or interception of the merchant'scommunications to the payment-processing bank or applicable credit cardprocessing network. Such systems and methods also fail to provide forany additional data gathering, authentication, and verification for andby any third party whose approval is normally required to conclude thetransaction.

U.S. Pat. No. 6,088,683 to Jalili describes a method for customers toorder goods from merchants on one network, such as the Internet, andthen complete the purchase via a second network, such as the telephonenetwork, using “Caller ID” service or a call-back to check thecustomer's telephone number as a form of proof of the customer'sidentity, and involving an independent processing center that receivesthe customer's financial information over the second network in advanceand stores it for future reference, The merchant uses the second networkto deliver transaction details and the customer's ID to the processingcenter, which then uses the second network to receive or initiatecontact from/to to the customer to check his/her identity and his/herpurchase intentions. Said method revises the method described in U.S.Pat. No. 5,727,163 to Bezos, by moving responsibility for the exchangeof the customer's financial information from between the customer andmerchant over a second network at the time of the transaction, as perBezos, to between the customer and processing center over a secondnetwork in advance of the transaction. In Jalili, the processing centeralso performs the step of debiting and crediting the accounts of thecustomer and merchant, respectively. Therefore, the utility of thismethod is limited to cases wherein both a purchaser and a merchant areindependently willing and able to establish an advance relationshipwith, exchange private information (such as account information for thepurchaser and merchant processing information for the merchant) with,and allow debiting/crediting of their accounts by, such a processingcenter prior to entering into a purchase transaction between themselves.The method is also limited to purchases, and particularly to purchasesinvolving a single customer and a single merchant. The need for apreparatory process occurring over the second network, the need to usethe second network to perform all steps to prepare and conclude atransaction other than the step of the customer's placing of his/herorder, and the need to establish a processing center, also limit theutility of this method. Because the purchaser does not actually supplyhis/her payment information to the merchant, the method further createsan opportunity for fraud perpetrated within processing center, stemmingfrom its unique position of trust between the two other parties. If,however, the processing center is not independent of the merchant, thenany utility derived from the separation of the processing center fromthe merchant, such as the assurance to the customer that his/her privateaccount information need never be transmitted directly to the merchant,is lost. The method also adds the complication of the merchant having toprovide a new and additional or alternative form of customeridentification information to the processing center in order to receivea customer's payment. The method also fails to provide for anyadditional automated data gathering, authentication, and verificationfor and by a party regarding non-purchase transactions, such as theopening, closing, or modification of an account remotely; nor for and byany third party whose approval is normally required to conclude apurchase transaction. The method also fails to address purchases ornon-purchase transactions initiated other than via a network. Lastly,the method requires a new sort of account to be established, namely, thecustomer's registration with the processing center.

Additional weaknesses and limitations of the prior art in generalinclude:

Systems and methods of physical recognition: Such systems and methodsrequire deployment, training, and support of a new purchaser and/ormerchant transaction-processing infrastructure on a wide scale (such asdeployment of biometric scanners and related interfaces to paymentsystems) and require the physical presence of purchaser to interact withthat infrastructure to complete a transaction. This solution istherefore highly limited in the scope of its application.

Systems and methods using passwords and ID codes: Generally effectivefor ATM and debit card transactions, such systems and methods are notused widely for credit card transactions. Passwords and codes (such asPIN codes) remain subject to theft (as by Internet hacking, card“skimming”, identity theft, etc.). Once a password or ID code iscompromised, no further safeguards are possible, and entirely newcustomer accounts must be created. Passwords and ID codes are notcommonly used, supported and enforced by merchants for credit cardpurchases.

Systems and methods using CVV2/CVC2/CID codes: Systems and methodsutilizing such codes are presently limited to credit card accounts only,do not protect against the loss or theft, such as by hacking, of creditor debit-and-credit cards or card account numbers along with such codes,and do not prevent the fraudulent creation or subsequent modification ofan account.

Systems and methods using verification of private knowledge: Suchsystems and methods are vulnerable to theft of private information viahacking, and identity theft. This is particularly troublesomeinternationally, where the most common type of private knowledgechecking in the U.S. for credit card transactions, namely, an account'sbilling addresses, is rarely possible today abroad.

Systems and methods using smart cards: While smart cards add password(PIN) features and can also create dummy credit card numbers usable forone transaction only, systems and methods utilizing smart cards requirethe installation and use of a smart card reader by the user, and havethus had limited adoption by consumers. These special features arefurther available only when purchases are made via the computing devicewhere the smart card reader is installed.

Systems and methods using digital signature information (“E-Wallets”):As with smart cards, systems and methods for e-wallets requirespecialized software to be installed on the computing device of thee-wallet's owner, and therefore have not been widely adopted byconsumers. Their features are likewise only available for purchases madevia the computing device where such software is installed.

Other limitations and weaknesses in the prior art: Notification of atransaction, and any interaction with the actual party or parties whoare truly authorized to conclude and approve it, as opposed tointeraction with parties who are perpetrating fraud by representingthemselves as said actual, authorized parties, is generally leftunaddressed by the prior art. Notification or interaction which doesoccur in the prior art is typically after the fact, either by theactual, authorized party's reviewing his/her billing or accountstatements, by consulting his/her credit report via a credit reportingagency, or, if the payment processor (for example, the relevant creditcard processor or bank) so determines, through a follow-up telephonecall from a customer service representative of such credit cardprocessor or bank, or through other messages delivered after the factthrough a variety of basic communications media. These inherentlyafter-the-fact processes do not interrupt or halt a fraudulent remotetransaction before it is completed, nor can they halt additionalfraudulent transactions (which may fit within a purchaser's normal riskprofile) made quickly thereafter using the same account number or otheridentifying information. Prior art which attempts to address theobjective of verification of a transaction before it is concluded addsprohibitive requirements for the establishment, registration with, anduse of intermediaries such as processing centers between customers andmerchants, fails to address the objectives of notification and approvalof or by third-parties, and fails to address the class of transactionscomprising the opening, closing, and modification of accounts.

It is desirable to verify and authenticate a transaction, and inparticular a potentially risky transaction, without relying on theinstallation and use of new equipment by one or more of the partieshaving an interest in, involved in, or represented to be involved in,said transaction, nor requiring substantial alterations to existingprocesses or additional education and training for conducting suchtransactions, nor requiring new intermediary entities to be established.It is further desirable to do so in a manner that thwarts any potentialparty to such a transaction who attempts to authorize or enter into itfraudulently. It is further desirable for such verification andauthentication to work even when the mechanisms, systems and methodsdescribed in the prior art may already be in use but still fail toprotect fully against fraud, especially when fraud is perpetrated as aresult of the theft of private information. This is especially importantin the area of transactions conducted remotely, and in particularelectronically. It is also desirable to notify automatically the actualparty or parties having legitimate authority to approve or audit atransaction, whether directly engaged in such transaction or not, of theoccurrence and/or details of said transaction. It is also desirable tobe determine the behavior of any embodiment of a system and method forsuch notification, verification and authentication, through the use ofstored profiles of parties and transaction types and other parameters,and also through profile information and other parameters which may beprovided with and as part of an individual transaction.

The invention described herein provides a method and system forverifying, authenticating, and providing notification-of a transactionsuch as a commercial or financial transaction, with and/or to at leastone party represented or identified as engaging in said transaction orhaving a potential interest in said transaction or type of transaction,in particular a remote or electronic transaction, while it occurs and/orafter it occurs, via one or more of a plurality of communication linksand communication addresses associated with said at least one party, soas to create a higher degree of certainty that the transaction isnon-fraudulent than is possible using any of the prior art, withoutintroducing significant delay in the completion of legitimatetransactions, and without requiring implementation of new equipment orsoftware, or learning of unfamiliar processes or technologies, orestablishment and use of separate processing centers or otherintermediaries.

BRIEF SUMMARY OF THE INVENTION

It is an object of the invention to provide a means of verifying andauthenticating the identities and intentions of one, some or all partiesrepresented or identified as engaging in a transaction or having apotential interest in said transaction or type of transaction while itis in progress, and/or soon thereafter;

It is also an object of the invention to provide a means of accepting orobtaining information and parameters about said transaction, includinginformation about one or more parties represented or identified asengaging in or having a potential interest in said transaction, from atransaction-processing system or device, such as a banking transactionsystem or credit card authorization or risk assessment system, as it isprocessing the transaction;

It is also an object of the invention to provide a means ofcommunications with and/or to one or more parties having a potentialinterest in the transaction, some of whom may be represented as engagedin the transaction through the use of identity-related data, such as anaccount number or numbers;

It is also an object of the invention to provide a means of defining, atthe time of the transaction or in advance of the transaction, or both,which specific parties have a potential interest in a given transaction,and the nature of such interest;

It is also an object of the invention to allow said communications tooccur over a plurality of communications media and/or communicationslinks, to increase the likelihood of successful and secure communicationwith and/or to said one or more parties;

It is also an object of the invention to provide a means of defining,initiating and controlling said interactions and their content;

It is also an object of the invention to provide a means of obtainingand/or storing information about the nature, communication addresses,and other parameters of said one or more parties' communications devicesused for said communications, to enable additional verification andauthentication of the identity or identities of said one or moreparties;

It is also an object of the invention, in its preferred embodiment, toallow the behavior of said preferred embodiment to be controlled andmanaged under varying conditions and circumstances in accordance withstored profiles and, additionally or alternatively, in accordance withinformation provided along with the transaction information;

It is also an object of the invention to provide a means, in itspreferred embodiment, for the adapting the inventive systems' behaviorbased on prevailing conditions and circumstances regarding saidtransaction, which conditions and circumstances may change during orbecause of the utilization of the invention;

It is also an object of the invention to provide a means of recordingand remembering the details of said transaction and the result orresults of any subsequent communications for later review and use by theuser of the invention;

It is also an object of the invention to provide a means of reportingand/or transmitting and/or forwarding a result or results regarding saidtransaction and said result or results of said subsequentcommunications.

Accordingly, the invention, to address the above and other objects,provides a system and method for verifying, authenticating, andproviding notification of a transaction, such as a commercial orfinancial transaction, with and/or to at least one party represented oridentified as engaging in said transaction or having a potentialinterest in said transaction or type of transaction, in particular aremote or electronic transaction, while it occurs and/or after itoccurs, and in accordance with any parameters which may be supplied inor with information about the transaction, additionally or alternativelywith any profile or profiles which may be associated with thetransaction.

In the preferred embodiment of the invention, the occurrence ofcommunications with said at least one party and at least one of aplurality of communications devices and associated predeterminedcommunications addresses known to belong to said at least one party,using at least one communications link other than the communicationslink used to initiate the transaction itself, isolates the transactionmedium or environment from the notification and/or verification mediumor environment, such that a very high degree of accuracy andcompleteness of authentication and verification can be achieved with aminimum of delay, and without requiring any newauthentication/verification technologies to be implemented or learned bythe transacting party or parties.

The invention goes beyond current practices by providing a highlyautomated means and a method for, individually and in combination:

-   -   1. Notification, verification and authentication of any or all        of the party or parties involved in, identified as involved in,        and/or predetermined to have a potential interest in, a        transaction while it is still in progress, and/or afterward;    -   2. Verifying and authenticating using a plurality of        communications links which may operate on networks having        near-universal, worldwide availability and high reliability;    -   3. Separating and isolating the communications link and/or        medium of the initial transaction (for example, the World Wide        Web) from the communications link(s) and/or medium or media used        to verify and authenticate it (for example, the public switched        telephone network, wireless networks, Instant Messaging        services), in such cases as the transaction's primary medium is        deemed insufficiently secure or insufficiently able to verify        and authenticate a party or parties;    -   4. Utilizing a plurality of concurrent and/or sequential        communications with and/or to a plurality of communications        devices and addresses, using a plurality of communications links        and communications media;    -   5. Attempting communications with and/or to any or all of the        party or parties involved in, identified as involved in, and/or        predetermined to have a potential interest in transaction using        alternate communications links or media in the event that        attempted interaction or interactions using the preferred        associated communications link or medium fails;    -   6. Predefining and dynamically determining a plurality of        sequences of actions and communications to be taken under        differing conditions for differing transactions and differing        pluralities of parties thereto, based on information and        parameters regarding the transaction and/or user-definable        profiles regarding transactions, types of transactions, and/or        parties and potential parties involved in, identified as        involved in, and/or predetermined to have a potential interest        in such transactions;    -   7. Communicating with a third party or parties involved in,        identified as involved in, and/or predetermined to have a        potential interest in, who are not initially part of such a        transaction (such as an employer, parent, or law enforcement        official in performance of his/her duty), for purposes such as        seeking such third party or parties' approval thereof, or to        notify same;    -   8. Assigning one or more roles to one or more parties involved        in, identified as involved in, and/or predetermined to have a        potential interest in a transaction;    -   9. Interacting differently with each of said one or more parties        based upon his/her ascribed role;    -   10. Avoiding intrusiveness in the consummation of the        transaction, by eliminating the need to install and proactively        use any new or unfamiliar equipment, software, processes, or        purchasing methods by the party or parties having an interest        in, involved in, or represented to be involved in the        transaction;    -   11. Intermingling of parameter-based non-transactional        information, such as sales, marketing, product or support        information, with transaction and confirmation information in        said communications, and    -   12. Predetermining and/or dynamically determining the format and        content of said communications, such as via user-defined        templates and/or scripts.

The preferred embodiment of the invention associates one or morepredetermined communications devices and addresses, such as telephonenumbers or wireless SIP addresses, with a plurality of parties who mayhave an interest in, be involved in, or be identified as involved in, atransaction, and related identifying information, which may include anaccount number or credit card number. Such identity, device and addressinformation are preferably defined and stored in advance in anon-volatile storage or database in the form of a profile associatedwith each such party, or are additionally or alternatively provided tothe inventive system within or along with information about a specifictransaction.

When a transaction is initiated with reference to such party or parties,such as via identifiers such as credit card account number(s), bankaccount numbers, or Social Security Numbers (SSNs) or tax identificationnumbers, a central system then attempts to communicate via a pluralityof communications links with and/or to one or more of said plurality ofparties via at least one of each such party's known, predeterminedcommunications device(s), to notify the party or parties of thetransaction and, additionally or alternatively, to interact with theparty or parties to authenticate and verify their identities, intentionsand/or approvals in regard to the transaction. The invention furtherprovides several alternative means and methods for establishing suchcommunications with and/or to each such party, either in parallel orserially, in the event that the primary means and/or method associatedwith each such party is not successful. Each communication or set ofcommunications is preferably governed by logic rules, which may bepredefined or dynamically determined, and which may be encoded as ascript to be executed in or by the central system, said rules beingdetermined in part based upon a categorization of the transaction, theidentities or a categorization of one or more of said plurality ofparties, and/or other parameters obtained along with the informationdescribing the transaction.

Because each such interaction occurs with the actual owner/user of thecommunication device at a known and predefined communications address(such as his/her pre-verified wireless SIP address), if any partyengaged in the transaction is not the owner/user of said predefinedcommunications address, then 1) the interaction by definition alerts theactual owner/user to a fraudulent transaction in progress, and 2) thefraudulent owner/user is thwarted, because he/she will be physicallyunable to authenticate him/herself using the communications device foundat said communications address. Further, even if the fraudulent party isable to obtain such a communications device belonging to the trueowning/using party, the fraudulent party must still supply furtherauthenticating information presumed to be known only to the actualowning using party. Preferably, the communications linkage employed forsuch interaction is different from the communications linkage used toinitiate the transaction, thereby further limiting the potential forfraud and for the theft of private information.

Additional utility may be derived when the user of the invention is inthe role of a financial services organization, such as a credit cardissuer, payments-processing network, merchant processor or acquirer,employing the invention alongside or within itstransaction-authorization and/or account-management processes andsystems to reduce transactional risk for its merchant and/or consumercustomers. Such financial services organizations already have, in thenormal course of their business, advance knowledge of potential partiesto transactions, including identifying information and other parametersabout such parties which may include their account numbers and theircontact information, such as home telephone numbers, e-mail addresses,and wireless device addresses; knowledge of transactions relating totheir customers as they occur; and a presumed relationship of trust withsaid potential parties to transactions. Their advance knowledge andexisting trust relationships minimize their effort to implement andwidely deploy the invention for maximum utility. In addition to thefraud-reducing and fraud “early warning” benefit of the invention,financial services organizations may also benefit from improved customerrelationships through increased value-adding contacts occurring as aresult of the use of the invention, and from the resulting higher levelof service provided, Financial service organizations that employ theinvention may also benefit from the utility of a reduced perception bytheir consumer and merchant customers of the risks of conductingtransactions electronically or remotely. Note that the additionalutility to entities in the role of financial services organizations isnot inherently limited to such entities, nor is it the only additionalutility they may obtain. This and other additional utility may be alsobe obtained by other users, whether utilizing a similar or alternativeembodiment of the invention.

In the preferred embodiment of the invention, when a transaction messageis received by the central system from a second system or device, thecentral system parses the received message, authenticates said secondsystem or device, and then may use the parsed data values to determineor derive a set of corresponding rules that inform or define the centralsystem's subsequent actions and subsequent communications with or to arelevant party or parties over a plurality of communication links. Suchrules may be predefined, and if predefined are stored in advance in thecentral system's volatile and/or nonvolatile storage memory ordatabase(s). The central system takes a plurality of actions accordingto said rules.

In the preferred embodiment, the central system may establish aplurality of communications links, which may include but are not limitedto wireless and landline telephony, SMS and wireless text messaging,instant messaging, and electronic mail and other Internet Protocol (IP)transmissions, in a sequence defined by said rules, to reach a pluralityof parties having a potential interest in, involved in, or representedto be involved in, said transaction. The central system attempts tocommunicate with and/or to each of said plurality of parties via atleast one predefined communications device specifically associated withthat party.

As each of said communication links is successfully established, thecentral system preferably delivers information to the correspondingparty regarding the transaction, which information may include 1) thetransaction details, which may include the nature or purpose of thetransaction and/or a total price or amount, 2) additional information ofpotential value to said party, such as product-, sales-, service- and/ormarketing-related information provided by the other party/parties or athird party or parties, and 3) other parameters, which may includeidentifying information regarding one or more of said parties. Saiddelivery of information is preferably composed and formatted by thecentral system per a predefined message template or script that may berelated to the transaction or the type of transaction, thecommunications medium employed, and the language in which the party isknown to be conversant. For example, in a telephone call, said deliveryof information may be comprised of concatenated segments of prerecordedaudio and/or text-to-speech synthesis.

Each such party may then be prompted to confirm his/her identity andintentions, which may include providing a PIN code, CVV2/CVC2/CID code(for a credit card), or other unique and private identifier(s), such asthe initial letters of his/her mother's maiden name, which datum or datamay be predefined to the central system, or may be supplied within orderived from the initiating transaction message. A confirming action oractions may be performed by said party via said communications link,using a means appropriate to his/her corresponding communicationsdevice. For example, on a telephone, DTMF digits may be pressed toconvey the information prompted for by the central system.

Based on the results of said interaction(s) with said plurality ofparties, the central system preferably computes or otherwise derives aresult, which it then preferably transmits to said second system ordevice from which the transaction message originated, and/or to anassociated third system. Further, based on said retrieved stored rulesand/or said dynamically derived rules, the central system alsopreferably transmits one or more of a plurality of notification messagesabout said transaction and said result to one or more of said pluralityof parties, over a plurality of communication links, and may also logsaid results in a nonvolatile memory or other storage or database forlater retrieval, action, and for analysis, and/or for billing purposes.

The central system communicates through a plurality of communicationslinks using a plurality of communications protocols, configuredaccording to such rules as are to be supported and implemented in anyspecific embodiment of the invention. These communication links andprotocols may include but are not limited to wireless and wirelinetelephony (which may include text-to-speech processing, recorded speech,DTMF tones, and combinations thereof), electronic mail, instantmessaging fax, paging, Short Message Service (SMS) and other wirelesstext messaging, and other existing widely used services and protocols,as described more fully hereafter. In the preferred embodiment of theinvention, the central system also provides a means to add and delete aplurality of types of communication links and protocols, as such typesof communication links and protocols become available and desirable orcease to be available or desirable; and a means of receiving,translating, and acting upon a plurality of informational codes andformats of transaction message as may be provided by differing types ofsecond system or device originating such transaction message underdiffering conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1. System Diagram—Preferred Embodiment

FIG. 2. Application Programming Interface Generalized Schema

FIG. 3. Networking Configuration

FIG. 4. Remote Transaction Engine Communications Interfaces—DataMessaging Layer

FIG. 5. Rules Database View

FIG. 6. Profiles Database Views

FIG. 7. Party-Transaction Group Profiles Database View

FIG. 8. Communications Sequence Patterns Database View

FIG. 9. Scripts Database View

FIG. 10. Message Templates Database View

FIG. 11. Communications Subsystems: Telephony

FIG. 12. Communications Subsystems: E-mail

FIG. 13. Communications Subsystems: Instant Messaging

FIG. 14. Communications Subsystems: Fax

FIG. 15. Communications Subsystems: Paging

FIG. 16. Communications Subsystems: Wireless Text Messaging/ShortMessage Service

FIG. 17. Communications Subsystems: Wireless Telephony

FIG. 18. Communications Subsystems: IP Telephony

FIG. 19. Communications Subsystems: Internet Data Protocols—HTTP/HTTPSusing HTML/XML

FIG. 20. Communications Subsystems: WAP

FIG. 21. Communications Subsystems: Telex

FIG. 22. Communications Subsystems: FTP

FIG. 23. Communications Subsystems: SNAJRJE Datasets

FIG. 24. Communications Subsystems: EDI/EDIFACT/EDI-INT

FIG. 25. Generalized Process Diagram

FIG. 26. Communication Scripting Language Statements, Object Methods,Properties, and Environment Variables

FIG. 11-FIG. 24 are schematics of the links between a preferredembodiment of a system according to the invention and a range ofpotential communications devices used or usable by potential parties toa transaction,

DETAILED DESCRIPTION OF THE INVENTION

The invention achieves a very high degree of accuracy and completenessof authentication, notification and verification of a transaction andthe identity and intentions of one or more of the plurality of partiesrepresented as entering into or conducting the transaction, with aminimum of delay, and without requiring new authentication/verificationtechnologies to be implemented or learned by such parties, by:

-   -   a) Automatically communicating with and/or to the relevant party        or parties represented as conducting a transaction, such as an        electronic or remote transaction, using at least one        communications link which is typically and preferably other than        the one used to initiate the transaction itself, if any;    -   b) Communicating with and/or to said party or parties only on        communications devices having specific predetermined        communications addresses known to belong to them, as a mechanism        of additional authentication and verification;    -   c) Additionally or alternatively, further verifying said party        or parties' stated identities by cross-checking physical        information known or discernable about their communications        devices (e.g., telephone Automatic Number Identifier value) with        other, external sources of identity information (e.g., a        telephone number billing address database);    -   d) Notifying said party or parties of the transaction's details,        such as a merchant's identity, purchase amount, etc., through        said communications devices;    -   e) Additionally or alternatively, providing supplemental        information of potential utility to said party or parties, such        as sales, marketing, product and support-related information,        through said communications devices;    -   f) Additionally or alternatively, interrogating said party or        parties to further authenticate their identities and/or verify        their intentions regarding the transaction using said at least        one communications link;    -   g) Additionally or alternatively, further verifying said party        or parties' stated identities and intentions by obtaining        confirming input from said party or parties, through said        communications devices, which may include passwords or other        private knowledge (such as a predefined PIN code, predefined        CVC2/CVV2/CID code, or several initial letters of a predefined        security word such as a mother's maiden name) through said        communications devices;    -   h) Enabling communication with and/or to one or more of a        plurality of parties related directly or indirectly to the        transaction, some of whom may not have been identified or were        not known to either the initiating parties or to the system or        entity (remote to the inventive system) responsible for        processing the transaction, and    -   i) Supporting stored, user-definable profiles, rules, and        parameters regarding such transactions and such parties, which        profiles, rules, and parameters, in a preferred embodiment, are        used to vary the behavior of the inventive system and thereby        the sequence of steps followed in the inventive method.    -   outside the transaction environment itself. The above advantages        apply whether the transaction is still in progress, or after the        fact.

FIG. 1 presents a potential embodiment of a system consistent with theinvention. FIG. 25 shows a generalized process flow for authenticatingand verifying a typical transaction using said embodiment of a system,consistent with the invention.

In FIG. 1, a Remote Transaction Engine [1], such as a web e-commerceserver or a credit card authorization system or device, processes atransaction initiated by one or more parties. The RTE [1] may, forexample, be operated by a merchant conducting remote transactions (as byInternet or by telephone) with its customers; by two or more partiesseeking to exchange goods, services, or funds; by a financialinstitution conducting a financial transaction with a customer (as viaAutomated Teller Machine); by a payment processor organization in behalfof a merchant; by a payments clearing network in behalf of a paymentprocessor organization; by a payment-account issuer in behalf of thepayments clearing network and the customer; by a financial institutionor merchant establishing or modifying an account such as a creditaccount for a customer or prospective customer, or by a service bureauin behalf of any of these. The sole requirement of the RTE [1] is to beable to provide a data message via an application programming interface[11] (“API”) means, predefined specification means, or other equivalentmeans to the Central System [2] (“CS”) of the embodiment of theinvention, via any one of several standard communications protocols overa communication link or network [31]. This transaction-describingmessage shall hereafter be called the Transaction Message.

FIG. 4 presents a plurality of communication links which may be utilizedin an embodiment of the inventive system for receipt of said TransactionMessage from the RTE [1]. A plurality of preferred data communicationlink types [411-420] is shown, plus a voice-based communication linkbased on DTMF signaling [421]. The inventive system preferably furtheraccommodates adding other and future protocols [425] as interfaces forthem become desirable and available, and removing existing protocols asthey cease to be desirable or available. Different embodiments of theinvention may support varying sets of such communication links fromsystem to system, or on the same system over time.

The Transaction Message is received by the CS's [2] Data Messaging Layer[FIG. 1, 201]. The Data Messaging Layer [201] is comprised of varioushardware and software modules and interfaces for receipt, queuing andinterpretation of messages from a plurality of networks [FIG. 4], andmay be implemented, for example, using technologies such as messagequeuing middleware for data communications, and an Interactive VoiceResponse (IVR) unit for DMTF-based telephony messages.

The Transaction Message, if communicated over a public data network orother potentially insecure network, such as the Internet, may be furtherencoded or encrypted either in whole or in part by the RTE [1] for addedsecurity, such as with PM encryption or a similar standard encryptingprotocol, such as the Internet's TLS.

The preferred CS [2] in general is further comprised of one or moreprocessors; memories and data storage; software and software libraries,such as may be written in and accompany the C++ and Java programminglanguages, for handling and manipulating said message as describedhereafter; an operating system for managing low-level elements of thesystem; security elements, such as firewall and/or encryption software,for limiting external access to the system, encrypting content, anddefending against various forms of electronic attack upon it; and,database or other data-managing software, to store, manage, and performsearches and retrievals on information about parties, transactions,transaction processing rules, communication methods, and the like, asmore fully described hereafter. The CS [2] is additionally comprised ofa range of communications hardware and software, collectively referredto as the “Communications Subsystems,” which are used to notify orinteract with one or more of a plurality of parties represented oridentified as engaging in a transaction or having a potential interestin a transaction. Said Communications Subsystems [211-218.ff.] aredescribed further hereafter.

The minimum necessary contents of said Transaction Message are shown inFIG. 2. The choice of minimum necessary contents may vary fromembodiment to embodiment of the inventive system. These data fields andvalues 1) identify the transaction-originating entity [2 a], 2) providea mechanism to authenticate it [21 b], 3) identify one or more partieshaving a potential interest in, involved in, and/or represented to beinvolved in, the transaction [22 a, ff. 22 b, ff], 4) identify the typeof transaction [22 c], such as a credit card purchase withcard-not-present, and 5) identify the price or amount of the transaction[22 d] if applicable. Preferably, the types of transactions known to thesystem are all user-definable in advance through the User Web Client[FIG. 1, 251] (see below) or via a bulk or automated load to the CS's[2] databases.

Additional data fields and values may be supplied in the TransactionMessage to further define the party or parties' communication addressesto be used in authenticating this transaction [23 c,f, ff., 23 d, ff.];a specific stored Rule Set (see below) to be invoked [23 i]; a specificstored message content template to be used either for this transactionin general [23 j,k] or for each party [231, ff.]; additional informationto transmit to the relevant party or parties during the communicationssessions which follow [23 o,p], and the like, as enumerated more fullyin FIG. 2. There is also specific provision for a mechanism to includeuser-defined fields and data values within said Transaction Message [23p]. These additional data in the Transaction Message, if present,preferably supersede such values as may be stored in advance in the CS's[2] databases about a given type of transaction, parties, Rule Sets, andso on.

The message protocol and format of the Transaction Message is definedaccording to the physical or logical port and/or communication servicethrough which it arrives at the CS's [2] Data Messaging Layer [201], andadditionally (for certain types of Internet messages) according tometa-tags and/or content-descriptor codes found at the start of themessage which further define the formatting and content of the message.The message is parsed by the Data Messaging Layer [201] according tosaid format and protocol, and thereby decomposed into a series ofname-value pairs which correspond to the data fields shown in FIG. 2.The incoming data are thus normalized into a standard and internalformat for subsequent processing, independent of their originatingformat.

If the minimum required information as identified in FIG. 2 is notpresent, or if the RTE [1, 21 a-b] cannot be authenticated, the CS's [2]Data Messaging Layer [201] rejects the Transaction Message and sends acorresponding rejection message back to the RTE [1]; in a typicalembodiment, the rejection message is composed and transmitted via thesame protocol used for receipt of the incoming message [FIG. 4,421-431].

Where any name-value pair is not defined in the message, default valuesare looked up in the CS's [2] primary database tables and views [FIG.5-FIG. 8] using the RTE ID [21 a], transaction type [22 a] and partyidentifiers(s) [22 a ff.], as the index values, via, for example, an SQLquery or a stored (database) procedure. Note that the CS enforces thatany variable-length lists of required name-value pairs, such as the listof parties, require at least one name-value pair be explicitly definedin the incoming Transaction Message for said message to be deemed valid.

If any of the parties is a member of a Party Group, either by priorassociation therewith through the CS's [2] Parties database view, shownin FIG. 6 [6 d], or as superseded by data in the Transaction Message,per FIG. 2 [23 f], the Data Messaging Layer [201] adds the identities(FIG. 7, 7 c] and roles [7 e] of the parties belonging to thecorresponding Group to the list of parties to be contacted for thetransaction. Relevant SQL statements to determine all additional partiesand their roles for a given transaction, based on an initial set ofparties:

-   -   SELECT DISTINCT [Party ID], [Party Role] FROM [Groups] INNER        JOIN [Transaction Parties] ON [Groups].[Party Group        ID]=[Transaction Parties].[Party Group ID] WHERE [RTE        ID]=$PartyID[0]$;    -   (where $xxx$ indicates substitution of the value of environment        variable ‘xxx’, per FIG. 26, and [Transaction Parties] comprises        the IDs of the parties who were specified in the original        transaction message received from the RTE [1]).

In this way, certain transaction types for a given party mayautomatically spawn communications with additional parties, such as anemployee's work supervisors or auditors, a minor's parents, or lawenforcement personnel, without requiring explicit mention of suchadditional parties in the incoming Transaction Message. Such Groups arepreferably user-definable in advance, via the mechanism of the Profiledatabases [FIG. 6] and the User Web Client [FIG. 1, 251]. This featureof the invention creates significant advantages over the prior art, byallowing automatic inclusion of a variety of additional parties inapproval, notification and auditing roles.

Each party is given a Role in accordance with its Profile [FIG. 6, 6 k],if any; its inclusion via the Party Group mechanism [FIG. 7, 7 e]; or,as superseded by data in the Transaction Message, per FIG. 2 [23].Another important advantage of the invention is the automatic assignmentof Roles to the party or parties of the transaction, such that differentactions may be taken in regard to each party based upon not only theparty's identity but also the Role of the party in the transaction. Oneembodiment of the invention uses roles such as “Confirm” for a partythat is to provide input to the inventive system, once contact has beenestablished therewith, for example to further authenticate his/heridentity and re-approve the transaction; “Notify” for a party that isonly to be made aware of the transaction by the inventive system, and“Present” for a party with whom contact is not to be established, butwhose related data and parameters are to be consulted and validated bythe inventive system as part of the computation and delivery of a resultmessage to the RTE [1].

Once the incoming Transaction Message's contents are validated, the fulllist of target parties and their roles is defined, and all relevantname-value pairs that enable subsequent processing are established, thena software-based object or other data structure (the “TransactionObject”) containing these data is created in the CS's [2] volatileand/or nonvolatile memory or storage. The Transaction Object is thenqueued for subsequent processing by the Rules and Script ProcessingLayer [202] (“RSP”) of the CS (2).

The RSP [202], in addition to sharing the basic elements of the CS [2]as described above, is comprised of programming and database logic forthe execution of both stored and dynamically-defined Action Scripts,where such Action Scripts define generalized, parameterized processesfor communicating with and/or to one or more parties. The basicfunctions and components of such Scripts are shown and described indetail in FIG. 26. The concept of fully user-programmable, adaptive,dynamic logic to control both the processing of individual transactionsand the execution of the related communications with one or more of itsparties is an important innovation introduced in and enhancing the valueof the invention, by allowing the inventive system to perform a varietyof distinct actions and sequences of actions based on each transaction'stype, parties and roles, and prevailing conditions and parameters, andon the real-time progress of the transaction through the inventivesystem.

The RSP [202] draws on the queue of work created in the CS's [2] memoryor other storage by the Data Messaging Layer [201], each work item beingone Transaction Object comprised of 1) name-value pairs describing thetransaction, as manipulated by the Data Messaging Layer [201] andavailable to scripts as Environment Variables (see FIG. 26), 2) anassociated Script, designated as described below, and 3) an evolving setof pending and actual communications link sessions and the resultsthereof, further described below.

Transaction Objects may be drawn from this queue in sequential order,unless there is an overlap among the identified parties of two or moresuch Transaction Objects. In such a case, the following logic ispreferably applied: 1) If the parties' roles are all, for example,“Notify” [per FIG. 6], the Transaction Objects may be merged, such thatmultiple notifications of multiple transactions may be sent to the sameparties using the same communications sessions. 2) If any of theparties' roles are, for example, “Confirm”, then the second TransactionObject is not drawn from the queue by the RSP [202] until the RSP [202]has completely finished working on any prior overlapping TransactionObject(s). This gatekeeping logic creates a unique advantage byprohibiting conflicting (and potentially confusing, or inherentlyfailure-prone) communications link attempts to the same party or partiesat the same time.

The Script associated with a given Transaction Object may preferably bedetermined as follows. First, the Rule Set [FIG. 2, 23 i] for thetransaction, if identified in the incoming Transaction Message, is foundin the Rules database view [FIG. 5] using, for example, an SQL query orstored (database) procedure. If it was not so identified, acorresponding default Rule Set matching the transaction type and partyis found in the CS's [2] Profiles database view [FIG. 6, 6 e] using, forexample, an SQL query or stored (database) procedure. If thecorresponding Rule Set returned by the query is null, a System DefaultRule Set may be used in its place.

Once the Rule Set is known and associated with the Transaction Object,its record in the Rule Set database view may be used to provide thefollowing information, which may be used to control the furtherprocessing the transaction, per FIG. 5:

-   -   Message Template ID [5 b], along with the Transaction Language        [5 d], defines what message template (per FIG. 10) will be used        to generate the contents of the actual communications with the        party (or parties) for this transaction. This value becomes an        Environment Variable (see FIG. 26) for the transaction.    -   Message templates consist of free-form text with embedded field        substitution codes and file insertion codes, which may be of a        form such as “$xxx$”, where ‘xxx’ is the name of an Environment        Variable (see FIG. 26), $file://yyyyy$ where ‘yyyyy’ is a        filepath on the Central System [2], and $=zzzz(xxx1, xxx2, . . .        )$, where ‘zzzz’ is a script function name and ‘xxx1’, ‘xxx2’,        etc. are Environment Variables passed to the function identified        by ‘zzzz’. In the “file” case, the contents of said file are        inserted in the message template in place of the “$file:// . . .        $” marker. In the other two cases, the variable or function is        evaluated and the results thereof are inserted in place of the        substitution marker.        -   A message template is defined by an ID and by a language,            such as “English”. Therefore, a single message template may            have multiple instances across multiple languages,            distinguished by the values in the “Language” field from            record to record.        -   Message Template Stylesheet URL [5 c] alternatively or            additionally allows a web-based stylesheet, such as an            XML-based (i.e., XSL) document, to be retrieved and used to            format the aforesaid message to the party (or parties), via            reference to a Universal Resource Locator (URL). This            provides the advantage of allowing the operator or user of            the RTE [1] to dynamically redefine the presentation of            information to the relevant parties merely by updating an            accessible web site with a new presentation format            applicable to one or more of the transactions said RTE [1]            may originate.        -   As such, this aspect of the inventive system is an important            innovation, by providing its users with a programmable            message content and formatting mechanism that need not be            maintained in or supplied to the inventive system, but may            instead be incorporated dynamically, by reference, at the            time the transaction is processed.    -   Transaction Language [5 d] is used along with the Message        Template ID [5 b] to define the message template.    -   Transaction Currency [5 e] is used when financial amounts are        referenced in the communication to or with the party or parties.    -   Confirming Value Type [5 f] defines what form and format of        datum is required as input from the party to successfully        authenticate and verify the transaction and the party's        identity. It may be a value such as “PIN” for a PIN code, or        “CVV2,” “CVC2,” or “CID” for a credit card confirmation code,        for example.    -   External Media Address Reference Flag [5 g], if True, indicates        that an external database call shall be made to a service        provider [FIG. 1, 12, “Remote Data Sources”] or other external        data source which can provide additional information about the        party's communication address or identity, such as the billing        telephone address for the party's home telephone number, for        cross-referencing and/or logging purposes and/or for later use        in computing the result for the party.    -   Allowed Media [5 h] encodes, such as in a text string or binary        value, the types of communications links and/or media applicable        to this type of transaction for this party. This media list acts        as a filter on the party's communication profile records [FIG.        6], limiting the communication link alternatives for the party        to only those link and/or media which are coded for in the        Allowed Media [5 h] field. For example, the party may have        e-mail as one communication preference, but for a certain        transaction type, the Allowed Media [5 h] filter value keeps        e-mail from being used to authenticate and verify the party and        his/her intentions for the transaction, for example to avoid the        time-delay and relatively low level of security associated with        e-mail-based communications, while for other transaction types,        e-mail is still used, in accordance with the Profile. The RSA        [202] insures that in no case are fewer than one communication        link alternative in force under any circumstances, even if the        use of that one alternative would otherwise violate the Allowed        Media [5 h] filter.    -   Script ID [5 i] defines which Action Script [FIG. 9 and FIG. 26]        is to be employed for the transaction. (The Script defines how        the CS [2] will interact with the party or parties hereafter.)    -   Default Communications Sequence Pattern ID [5 j] identifies the        default communication strategy to be used when attempting to        reach the party or parties. This value may be overridden by any        Communication Sequence Pattern [FIG. 6, 6 n] defined in the CS's        [2] databases, or in the Transaction Message, for any specific        party or parties for this transaction type.

Once the above data have been gathered and stored in the system's memoryor other storage along with the other transaction information aggregatedinto the Transaction Object, the RSP [202] executes the aforesaidScript. In general, Scripts preferably 1) attempt to establishcommunication link sessions simultaneously with all relevant partiesassociated with the transaction, and where possible, 2) deliver messagesto the parties over such communication link sessions, 3) prompt for andaccept input from the party of parties defined as having, for example,“Confirm” Roles [FIG. 6, 6 k; FIG. 7, 7 e], 4) compute an overall resultsummarizing the outcomes of all such communications and communicationattempts, 5) optionally log the transaction, communication attemptresults, and said outcomes and overall result, and 6) communicate theresult back to the RTE [1].

An important advantage of the invention is the adaptive logicrepresented by such Scripts, in lieu of a static process logic mechanismthat executes a single statically-defined sequence of instructions inevery case and under every condition.

In general, for each party, the preferred embodiment's RSP [202] willperform the following standard actions under the control of the Script[5 i]. Note that communications to multiple patties will occursimultaneously (unless directed otherwise by said Script) viaconcurrently executing, asynchronous system processes in the CS's [2]Communications Control Layer [203] (“CCL”). The process flow for thepreferred embodiment of the invention, with the RSP [202] executing aScript, is diagrammed in FIG. 25, in which the RSP [202] will perform inaccordance with a method comprising the steps of:

-   -   1. Perform an external database or data service query or        reference [B], as of, for example, a telephone number billing        address database, using relevant data about the party as a key        (for example, his/her telephone number), to gather external data        about the party for use in computing the result for the party        and the overall result message to the RTE [1], provided the        External Media Address Reference Flag [FIG. 5, 5 g] (see above)        for the transaction's Rule Set is True [A].    -   2. Consult the party's Communication Profile record [FIG. 6, 6        a-c, 6 i-o] for this transaction type and account number (if        applicable), using an SQL query or stored (database) procedure,        and then:        -   a. Group all the corresponding communication devices,            addresses, and media for the party by their Communications            Sequence Group [61] (“CSG”) number, if applicable;        -   b. Where no CSG number is assigned to a communication            device, a distinct temporary CSG is assigned by the RSP            [202] to each such device;        -   c. Order the CSGs by the associated Communications Priority            [6 m] number; this step defines the order in which the            party's communication devices will be tried, with the Group            mechanism of step (a) collecting multiple devices to be            tried together simultaneously;        -   d. Identify i) the party's Role [6 k] for this device,            address, and media type (noting that not all supported            devices and media types necessarily support two-way            interactive communications), ii) the expected Confirmation            Value [6 o] if any, for “Confirm”-type parties (noting that            this value may have been additionally or alternatively            supplied in the incoming Transaction Message from the RTE            [1] and the confirming value may be stored in this field if            the CS [2] is securely operated by the financial            organization which supplied this value for the party's            account [6 c], and may be omitted in other cases, or at the            financial organization's discretion. When omitted, any            Confirming Value [6 o] must be supplied by the RTE [1] in            the Transaction Message received from the RTE [1]—ideally            with encryption applied), and iii) the Communications            Sequence Pattern ID [6 n].    -    The above steps (a)-(d) are aggregated in FIG. 25 as process        box [C], “Select Party's next device Group (CSG)”.    -   3. For each Communications Sequence Group [6 i] for the party,        in ascending order of Communications Priority [6 m], initiate        simultaneous, multithreaded communications sessions to all        devices within said CSG [61] via the Communications Control        Layer [203] (“CCL”) [FIG. 25, D]. The CCL [203] initiates such        sessions via commands it issues to the Communications Subsystems        [FIG. 1, 212-218 ff.]    -    A Communications Sequence Group [61] with more than one        communications device and address in it causes the CCL [203] to        attempt to reach a single party simultaneously on a plurality of        his/her devices and addresses. The first such contact attempt to        succeed [E] becomes the sole active communication session to the        party, and all other sessions are immediately, automatically        terminated [F]. This is accomplished through the CCL's [203]        monitoring and analyzing session-progress events [per FIG. 8, 8        k: “Generate Event on Connection Flag”] generated via the        various Communications Subsystems [FIG. 1, 211-218 ff.]. In        practice, most Communications Sequence Groups [61] will contain        just one device and addresses, and thus just one communication        session at a time will be attempted for each party.    -    Once a communication session is successfully initiated with a        party on a given device and at a given communication address        (such as a telephone with a particular telephone number) in a        “Confirm” Role [FIG. 6, 6 k; FIG. 7, 7 e], as per FIG. 25 [1],        no further attempts to interact with that party in its “Confirm”        Role for the current transaction are preferably made. However,        further communications may preferably continue to occur in a        “Notify” role. This may be accomplished by the CCL [203] setting        a flag or semaphore (FIG. 25, 1] for the party (such as the        PartyConfirmed[n] Environment Variable per FIG. 26) once one        “Confirm” contact has occurred, such that further “Confirm”        devices are ignored by the CCL [203] for the current party in        the current transaction [FIG. 25, M].    -    This feature contributes a special advantage of the invention,        by allowing a given party to engage in contact with the        inventive system in multiple Roles for the same transaction,        such as, for example, a “Confirm” Role on his/her mobile Instant        Messaging device and a “Notify” Role to his/her e-mail system.    -   4. Each communications device for the party has an associated        user-defined Communications Sequence Pattern [FIG. 8, 8 a] that        is used to manage the attempts to reach and establish a        communication link session with the device; for each such        Pattern, consult Communication Sequence Pattern (8 a] database        record, via SQL query or stored (database) procedure, to obtain        the following parameters, or the equivalent, in a preferred        embodiment of the inventive system:        -   Interactivity Flag [8 b], which specifies whether input from            the party is possible from said device;        -   Outbound Inbound [8 c], which specifies whether the            communication link is to be initiated by the CCL [203] or by            the party communicating inbound to the CCL [203];        -   Attempt Timeout Value [8 d], which sets the time before an            attempt is deemed to have failed (for example, for a            phonecall with multiple rings and no answer);        -   Sequence Timeout Value [8 e], which sets the total time            before an entire Sequence is deemed to have failed if no            successful connection occurs;        -   First Attempt Delay [8 f] which postpones the first attempt            at communication link session by a fixed amount of time (for            example, to allow a party to switch his/her line from data            to voice mode on a dual-purpose communication device);        -   Smart Retry Flag [8 g], which, if True, instructs the CCL            [203] to time subsequent communication attempts based on the            outcome of the prior attempt (for example, retrying a phone            number sooner if the last result was busy, vs.            ring-without-answer);        -   Maximum Number of Attempts [8 h], which defines a total            number of attempts allowed before conceding failure;        -   Attempts Spacing [8 i], which defines the timing between            subsequent attempts, and alternatively or additionally,            between specific attempts in the Sequence;        -   Action on Final Failure [8 j], which defines whether upon            the ultimate failure of the sequence, a new sequence should            begin (e.g., a Sequence Pattern in which the system waits            for the party to call it), or not, and        -   Generate Event on Connection Flag [8 k], which, if True,            instructs the communication process executing the connection            attempt to send an alert event to the CCL [203] upon            success. This event is used in conjunction with            Communication Sequence Groups [61] to identify which of a            series of simultaneous communication link attempts to a            party's several devices has succeeded first, and is thus to            be continued, the rest being terminated.    -   5. Dispatch these data, via the Transaction Object's Script, to        the CCL [203], which creates individual software processes        and/or threads of execution for each potential communication        link session based on the aforesaid parameters. (See FIG. 25,        “Script Execution” process block.) These processes record in the        CS's [2] memory and/or databases or other storage the results of        all sessions and session attempts for each party for each        transaction for later computation [L,R]. The design and        processes of said communication sessions is described hereafter.

Once each party's communication session a) occurs successfully and, ifin a “Confirm” Role, obtains the required input from the contacted party[FIG. 1, 5 f; FIG. 25, H,I], such as a PIN, password, or CVV2/CVC2/CIDvalue; b) occurs but fails to gather such required input from the party[FIG. 25, J,K], or, c) fails to occur after all attempt SchedulePatterns are exhausted [FIG. 25, N,Q], the RSP [202] is notified by theCCL [203] that all necessary sessions and contact attempts are complete[FIG. 25, S] The RSP [202] computes a result message [T] back to the RTE[1], said message being transmitted via the Data Messaging Layer [201],preferably using the same format and protocol as the receivedTransaction Message. Upon transmission of the result message, theTransaction Object is removed from the CS's [2] work queues and memory,and new Transaction Objects (if any) may then be processed.

Note that in a large-scale embodiment, the inventive system is likely toprocess a large volume of Transaction Messages and Transaction Objectsconcurrently, via multithreaded processing and load-balancing amongmultiple processors and subsystems, and its design should not beconstrued as requiring serial processing of Transaction Messages andTransaction Objects.

Communications Control Layer and Communications Subsystems

The Communications Control Layer [203] of the preferred embodiment ofthe inventive system coordinates and manages the activity of theCommunications Subsystems. The CCL [203], in addition to sharing thebasic elements of the CS [2] as described above, is comprised ofsoftware specific to the establishment and management of simultaneouscommunications link sessions across a plurality of media. Said softwaremay be implemented using such software frameworks and with suchapplication development tools and platforms as CallXML (an open-sourcemark-up language for creating server-based interactivetelecommunications applications) or the Adaptive CommunicationsEnvironment (an open-source software framework and library for managingsignaling, events, dynamic reconfiguration of services, and concurrentprocess synchronization for multithreaded real-time communications).

The Communications Subsystems are of three general types: 1)telephony-related for voice and audio communications, 2) Internet- anddata-related for data and text messaging, and 3) specialty data-networkrelated, for certain other types of data transfer such as EDI andSNA/RJE. The Communications Subsystems are each comprised of hardwareand software for transmitting and receiving signals to and from aspecific class of devices (terminals) over a particular communicationslink or links or communications network or networks using a specificprotocol or family of protocols. Each is further comprised of acollection of logical and physical ports, or other equivalentinterfaces, each capable of sustaining concurrent communications withone, or more where applicable, individual device(s) and/or terminal(s)across a corresponding communications link or network. (Said devices andnetworks are presumed to be external to the inventive system, but inother embodiments need not be.)

A high-level representation of a subset of the communications links andmedia supported by a preferred embodiment of the inventive system isshown in FIG. 1. A complete, low-level representation of thecommunications media, interfaces, links, and potentially supporteddevices for each Communications Subsystem for an embodiment of theinventive system is presented individually from FIG. 11 to FIG. 24inclusive.

The Communications Subsystems provide a layer of abstraction to the CCL[203], which is then able to interact with the various communicationmedia and devices of the party or parties to a transaction in terms ofgeneric communication sessions.

The following tables relate the communications devices and media and thenetworks which support them, per the aforesaid Figures. The first tableidentifies the media explicitly shown in FIG. 1.

TABLE 1 Profiled Communication Media, Related Networks, and Devices perFIG. 1 Communications Medium [Interface, Link] Associated NetworkPossible Device(s) Telephony [211, 511] Public Switched TelephoneTelephone, Key system, PBX Network [231] with extentions, PBX withdirect-dial, IVR, automated attendant [611] Electronic mail [212, 512]Internet Protocol networks Electronic mail software, e- (such as theInternet) [233], mail appliance, mobile e-mail private data networks(such as device (such as a PDA), e- frame relay networks), public mailcapable cell phone or data networks (such as the pager [612] MCI Mailnetwork) and services such America Online) [232] Instant Messaging [213,513] Internet Protcol networks Instant messaging software, (such as theInternet) [233] mobile IM device, IM-cable and IM-capable services (suchcell phone or pager [613] as America Online) [232] Facsimile [214, 514]Public Switched Telephone Fax machine, fax server, fax Network [231] oran IP fax modem, virtual fax inbox service or network (such as by system[614] Easylink Services Corp.) Paging [215, 515] Paging network (such asby Pager, paging-capable cell SkyTel) [234] phone [216] Short MessageWireless data/telephony Mobile text messaging device, Service/WirelessText network, PCS network [235] text-capable cell phone, Messaging [216,516] iMode phone [616] Wireless Telephony [217, Wireless telephonenetwork, Cellular telephone [617] 517] PCS network [235]

The following table shows media, networks, and devices are coveredindirectly in FIG. 1 under [218+], [236+], and [625+], but which areexplicitly described in FIG. 18-FIG. 24, inclusive. (Note that it is theintent of 1 [218+], [236+] and [625+] additionally to define the abilityof the inventive system to be expanded to accommodate additional oralternative communications media, networks, and/or devices over time asthey become desirable and/or available, and/or as implementedcommunication media, networks, and/or devices cease to be availableand/or desirable.)

TABLE 2 Additional Profiled Communication Media, Related Networks, andDevices per FIG. 18-FIG. 24 Communications Medium [Interface, Link]Associated Network Possible Device(s) Additional or alternativeAdditional or existing Additional or existing devices media, as becomenetworks as they come to as they come to support saiddesirable/available [FIG. 1, support said additional/alternative media218+] additional/alternative media [FIG. 1, 625+] [FIG. 1, 236+] IPTelephony [FIG. 18, 218, Public and private Internet Telephone, Keysystem, PBX 518] Protocol networks (such as the or IP PBX withextentions, Internet) supporting IP PBX or IP PBX with direct- telephonestandards such as dial, IP telephone, IVR, H.323 [233], and the PSTN byautomated attendant [618] using an IP telephony gateway [231] InternetData Protocols Public and private Internet Web server, or browser-basedincluding HTTP/HTTPS using Protocol networks (such as the system ordevice [619] HTML/XML [FIG. 19, 219, Internet) [233] 519] WirelessAccess Protocol Wirelss Internet Protcol WAP-capable mobile device (WAP)[FIG. 20, 220, 520] networks [233] and wireless or cellular phone [620]networks supporting Internet access through a wireless- Internet gateway[235] Telex [FIG. 21, 221, 521] Telex network [236] Telex terminal orTelex mailbox service [621] File Transfer (FTP) [FIG. Internet Protocolnetworks FTP server [622] 22, 222, 522] (such as the Internet) [233],private data networks (such as frame relay networks) and public dataservices (such as America Online) [232] SNA/RJE [FIG. 23, 223, SNAnetwork [237] or an RJE capable system or device 523] SNA-tunneling oremulating (such as an IBM S/390 data network [232] mainframe computerwith IBM 3770 RJE terminal or equivalent) [623] EDI/EDIFACT/EDI-INT EDIValue-Added-Network EDI capable server (such as [FIG. 24, 224, 524](such as the Sterling by Sterling Commerce, a unit Commerce VAN) or anEDI- of SBC Corp.) capable IP network or service (such as by InternetCommerce Corp.) [238]

The CCL [203] initiates one or more concurrent, multithreaded processeswhich queue requests to obtain communication ports from one or more ofthe Communications Subsystems [FIG. 11-FIG. 24] and then direct theCommunications Subsystems in establishing communication with and/or tothe party or parties to the transaction according to the Script andEnvironment Variables of the Transaction Object. The Script andEnvironment Variables, based on the data obtained from the Profiles,Groups, Rule Set and Communications Sequence Patterns database views[FIG. 5-FIG. 8], identify the parties and their communication devicesfor the given transaction, define a sequence for the occurrence ofcommunications with and/or to each applicable party, and specify whichcommunications links, networks, and protocols/media to use at variouspoints within said sequence.

The preferred embodiment of the inventive system provides for threegeneralized sequences for contacting a party: 1) attempting to reacheach device associated with that party sequentially, 2) attempting toreach each device associated with that party in parallel, and 3)combinations thereof. Further, each device may be tried several times insuccession until contact is established with it, as defined in itsassociated Communications Sequence Pattern [FIG. 8]. The EnvironmentVariables include information for the CCL [203] and CommunicationsSubsystems to use for timing out on an individual attempt and on asequence of attempts. The CCL [203] coordinates these patterns ofcommunication attempts through to their logical conclusion.

The inventive system also provides, through a correspondingCommunications Sequence Pattern definition, a mechanism to allow a partyto initiate contact with the system within an allowed time interval,using the Environment Variable “Inbound/Outbound” [FIG. 8, 8 c] inconjunction with “Attempt Timeout Value” [8 d] and “Sequence TimeoutValue” [8 e]. For this to occur, the communication address (such as atelephone number or Instant Messaging ID) of the device used by theparty must be universally and securely detectable by the appropriateCommunication Subsystem interface, such as with Automatic NumberIdentification (ANI) service for devices using the Public SwitchedTelephone Network [FIG. 11, 231] by the Telephony Interface [211].

When attempting to establish contact with a party's device, theappropriate Communications Subsystem executes a cycle of attempts, thetiming of which is defined by the values for the correspondingCommunications Sequence Pattern's fields, shown in FIG. 8, specificallythe values for First Attempt Delay [8 f], Smart Retry Flag [8 g],Maximum Number of Attempts [8 h], and Attempts Spacing [8 i]. The use ofthese party- and device-specific, user-predefined parameters to guidethe inventive system in its interaction attempts with a party providesthe invention with the advantage of a high degree of flexibility andeffectiveness in getting through to a party with a minimum ofdifficulty.

-   -   First Attempt Delay [8 f], if specified, provides for a        user-defined time to elapse prior to the first contact attempt,        so that, for example, the party may change a dual-use line from        data mode to telephone mode for the purpose of receiving a        telephony-based contact.    -   Smart Retry Flag [8 g], if True, indicates that the        Communications Sequence Pattern for the device shall be        self-modifying (under the control of the CCL [2031] based on the        outcome of each successive contact attempt. Particularly for        telephony-based communications, this mechanism allows the        inventive system to change the timing and quantity of future        attempts based on the condition of the device (or network) being        reached, as reported by such network to the respective        Communications Subsystem interface. For example, Instant        Messaging services provide a status indicator which may include        values such as “Active”, “Busy” or “Off line”; telephony        networks respond with, among others, answer-supervision (i.e.,        signaling that the call has been answered), busy signals, or        repeated rings without answer. Smart Retry provides, for        example, for increasing the frequency and number of attempts in        “busy” cases, decreasing in “off line”/“ring no answer” cases.    -   Maximum Number of Attempts [8 h] defines the total number of        attempts the inventive system should make to reach a device        before the respective Communication Sequence Pattern is deemed        exhausted. This value may be modified dynamically by the CCL        [203] if the Smart Retry Flag [8 g] is set.    -   Attempts Spacing [8 i] defines the time intervals between        successive attempts, either as a general value, or as specific        values for each attempt in the Sequence. This value may be        modified dynamically by the CCL [203] if the Smart Retry Flag [8        g] is set.

As shown in FIG. 25, in the “Communication Session” process block, anactive communication session with a party's device is comprised of thefollowing generic cycle of functional execution of elements of thepreferred embodiment of the inventive system and corresponding processsteps:

For the first successful “Confirm” Role session and for all “Notify”sessions, as such Roles [FIG. 6, 6 k; FIG. 7, 7 e] and associatedScripts [FIG. 9, FIG. 26] may be defined in a given embodiment of theinvention, an associated message template, per FIG. 10, is defined inthe Environment Variables [FIG. 26: “MessageTemplate[n]”] accessible tosaid Script. In a typical embodiment of such a Script, as soon as acommunication link session is reported as open and active by thecorresponding Communications Subsystem, the Script executionprocess/thread begins composing and transmitting the various segments ofsaid message template to the communication device [FIG. 25, G],formatted according to the capabilities and limitations of thecommunication device. For example, in a telephony communication linksession, the message may be reformulated by the use of a text-to-speechprocessor [FIG. 11, 711 a], and prerecorded audio may be interpolated bythe Telephony Interface [211] or related IVR processor [711 b], whereasfor an Internet HTFP session using XML, the message may be reformattedusing a referenced XMI, stylesheet (XLS), and text- or image-basedcomponents may be substituted for audio components of the message.

Particularly in the case of communications sessions requiring input fromthe reached party, the message may consist of multiple segments that arecomposed and delivered to the party's communication device serially bythe appropriate Communications Subsystem.

If an input is indeed required [FIG. 25, H], and the device supports it(per the Communication Sequence Pattern [FIG. 8, 8 b: “InteractivityFlag”]), the executing Script process will preferably prompt for andwait to receive input from the party. The form of the input depends onthe nature of the communication device and medium; for telephony-classdevices, it is typically and preferably in the form of DTMF tonesproduced by touch-tone dialing or, additionally or alternatively, viavoice, requiring the use of a voice recognition processor [FIG. 11, 711c]; while for Internet- and data-type devices, it is typically andpreferably through a return message (such as HTML <FORM METHOD=″POST″>,e-mail SMTP reply, Instant Messaging text reply); and, for a specialtydevice or terminal, such as an SNA/RJE device, it is typically andpreferably through a specifically formatted data exchange particular tothe protocol being employed.

The Script may define whether the input must be validated beforeproceeding, and if so, may give the party multiple attempts to entercorrect information before abandoning the attempt. Such attempts atreceiving input may further be governed by Timeout parameters (see FIG.26, “Transaction/Communication Session Object Properties”), such that,when the indicated time has elapsed, the attempt is abandoned [FIG. 25,J]. In an out-of-time case, or in such case as a predefined number ofinput attempts is initiated over the communication link session withoutsuccessful validation, the Script delivers a timeout message segment ifso defined in the message template [K].

If input was prompted for, a corresponding Environment Variable flag isset (see FIG. 26: “PartyConfirmContact[n]”) to identify that a “Confirm”Role session has attempted to gain input required from the party.

At the conclusion of any and all input-gathering and delivery of messagesegments, the communication link session is terminated (by theCommunications Subsystem, and optionally by the party as well if theparty reacts more quickly than the Communications Subsystem). Theresults may be stored [L] for use by the system later on.

If the session was successfully initiated (whether or not correct inputwas actually received), and was, for example, a “Confirm” Role session,as may have been indicated through the use of the aforesaidPartyConfirmContact[n] Environment Variable, further attempts to contactthe party in a “Confirm” Role (or equivalent, based on the embodiment ofthe inventive system) are preferably disabled for the currenttransaction.

For all non-“Confirm” devices, and if a “Confirm” Role contact has notyet been made successfully on any “Confirm” Role device, for example,the processes/threads executing the Communication Sequence Patterns inregard to the corresponding devices continue.

After the failure of an attempt, the attempt parameters andcorresponding failure data provided by the appropriate CommunicationSubsystem are preferably logged in the system's databases or othervolatile or nonvolatile memory or storage and, if there are furtherattempts allowed, per the effective Maximum Number of Attempts setting[FIG. 8, 8 h], the thread of execution for the applicable CommunicationSequence Pattern waits until the next attempt should be made, per 1) theAttempts Spacing value [8 i] corresponding to the next attempt in theSequence, and/or 2) the Smart Retry setting [8 g], as described above.This is shown in FIG. 25's “Wait per device's attempt schedule” processbox [O].

If the attempt schedule is exhausted, the executing process may initiatea new process with a new Communication Sequence Pattern, if suchadditional Sequence is defined for use upon the unsuccessful exhaustionof the current one [FIG. 8, 8 j: “Action on Final Failure].

This mechanism, an innovative advantage of the inventive system, allowsthe chaining of Communication Sequence Patterns to arbitrary lengths,executing until success occurs or the final Sequence in the chain ofSequences fails. It is also possible thereby (if only sometimesdesirable) to set up an endless cycle of communication attempts throughself-referencing chains of Sequences, such that the inventive systemwill attempt to establish contact with a party indefinitely, untilsuccessful. This is particularly useful in the case of a transactionwhich, by its nature and that of its parties, indicates an emergencysituation, such as an authorization transaction (non-commercial innature) regarding the entry by some party to a restricted or securedarea or system, or an extremely urgent and critical commercialtransaction requiring immediate confirmation by a party not otherwisedirectly engaged therein at the time.

It is further possible and desirable, under certain conditions, toestablish an inbound Communication Sequence Pattern [FIG. 8, 8 c], to beinitiated by the party, as a follow-on Sequence to an outbound Sequence.For example, a wireless text message may be sent to the party's cellulartelephone, which text message includes a callback hyperlink to anembodiment of the inventive system's Telephony Communications SubsystemInterface [FIG. 1, 211]. Simultaneously, an inbound CommunicationSequence Pattern is established which waits for contact from the party,similar to the underlying contact mechanism described in U.S. Pat. No.5,727,163 to Bezos. The party, by responding to the callback hyperlinkin the wireless text message, then interacts with the TelephonyInterface and is joined to the executing process which has been waitingfor his/her inbound contact.

The following Table 2 presents component technologies which may be usedby one skilled in the art to construct the communications interfaces andlinks shown in FIG. 11-FIG. 24.

TABLE 3 Possible Components of Communication Subsystems EmbodimentsAdditional system FIG. Interface Example resources Example 11 Telephony[211] Intel ® Dialogic ® Text to speech Nuance DM/V1200-4E1 processorCommunications, and D/320-PCI [711a] Inc.'s Vocalizer voice cards,Intel ® IVR [711b] Intel ® CT Media CT Media software Voice PersayInc.'s recognition Orpheus Speaker processor Verification [711c]Platform 12 E-mail [212] Sendmail Consortium's Sendmail e-mailingsoftware 13 Instant Messaging Jabber, Inc.'s (PC-based and Jabberwirelsss) [213] Communications Platform 14 Fax [214] Intel ® Dialogic ®Text to fax Inso's Outside In DM/F300-E1 fax processor Server cards,Intel ® CT [714a] Media software 15 Paging [215] Sendmail Consortium'sSendmail (for initiating SMTP- based alphanumeric pages) 16 WirelessText/SMS Simplewire, Inc.'s [216] Java SMS middleware, or Nokia Corp.'sMultimedia Email Gateway (and SMTP-to-SMS server) 17 Wireless TelephonyAs Telephony Text to speech Nuance [217] above processor Communications,[711a] Inc.'s Vocalizer IVR [711b] Intel ® CT Media Voice Persay Inc.'srecognition Orpheus Speaker processor Verification [711c] Platform 18 IPTelephony [218] Intel ® Dialogic ® Text to speech Nuance DM/IP301-1E1 IPprocessor Communications, Link boards for [711a] Inc.'s Vocalizer H.323and CT IVR [711b] Intel ® CT Media Media software Voice Persay Inc.'srecognition Orpheus Speaker processor Verification [711c] Platform 19Web-based (HTTP, IBM Websphere HTTPS, etc. using Application ServerHTML, XML, etc.) and HTTP Server; [219] optionally, IBM MQSeriesEveryplace 20 WAP [220] Nokia Corp.'s Activ Server 21 Telex [221] 22 FTP[222] IBM MQSeries FTP SupportPac 23 SNA/RJE [223] IBM 377x In a non-IBMSun Microsystems, Emulator; an system, an Inc.'s SunLink inherentfunction in ASCII- SNA 3770/RJE any IBM S/390-or EBCDIC software Z-classsystem converter 24 EDI/EDIFACT/ Sterling EDI translator SterlingEDI-INT [224] Commerce's [724a] Commerce's GENTRAN:Server GENTRAN:Serverand OFTP Plus

It is increasingly possible and practical for the physical interfacesand ports, such as those described above, to be substituted by InternetProtocol connections to service providers and service bureaus whichaccept IP-based inputs (such as SMTP-formatted e-mails) and translateand deliver such inputs to other types of device, such as fax, telex,and mobile browser-based devices. The inventive system, per itspotential embodiment(s) described herein, does not purport tospecifically require any particular interface type for the statedcommunication links or communication media, nor to require that messageconversion occur within the inventive system, rather than in and by anexternal service provider's system(s). The full scope and capability ofthe inventive system and method are enumerated in the invention'sclaims.

Message Templates

As shown in FIG. 10, message templates are preferably comprised offree-form text with embedded field substitution codes and file insertioncodes, which may be of a form such as “$xxx$”, where ‘xxx’ is the nameof an Environment Variable (see FIG. 26), $file:(/yyyyy$ where ‘yyyyy’is a filepath on the Central System [2], or a Uniform Resource Locator(URL) accessible to the Central System [2], and S=zzzz(xxx1, xxx2, . . .)$, where ‘zzzz’ is a script function name and ‘xxx1’, ‘xxx2’, etc. areEnvironment Variables passed to the function identified by ‘zzzz’. Inthe “file” case, the contents of said file are inserted in the messagetemplate in place of the “$file:// . . . $” marker. In the other twocases, the variable or function is evaluated and the results thereof areinserted in place of the substitution marker.

The use of a URL to supply some or all message contents is a powerfulinnovation, because it allows remote content and even remote templatesto be included dynamically and programmatically on atransaction-by-transaction basis (that is, without requiring anyuser-initiated changes or updates to the inventive system or itsdatabases' contents whatsoever).

A message template is defined by an ID and by a language [10 b], such as“English”. Therefore, a single message template may have multipleinstances across multiple languages, distinguished by the values in the“Language” field from record to record. A corresponding currency namemay also be associated for use with financial content in the messagetemplate, as per FIG. 5 [5 e].

In some circumstances, a stylesheet retrieved and referenced by aUniversal Resource Locator (URL) or Universal Resource Identifier (UDI)may be substituted for a stored message template or a message templatepassed to the central system [2] in the incoming Transaction Message.This powerful innovation allows mark-up methods of message contentdefinition and formatting definition to be applied remotely to theinventive system, on a transaction-by-transaction basis, dynamically andprogrammatically (that is, without requiring any user-initiated changesor updates to the inventive system or its databases' contentswhatsoever).

Rule, Profile, Script, Communication Sequence Pattern, and MessageTemplate Management

Prior to first use of the preferred embodiment of the inventive system,at least one entry is required in each of its various database views[FIG. 5-FIG. 8] (excluding the Group view), representing a default RuleSet, Party Profile, Communication Sequence Pattern, Action Script, andMessage Template for at least one type of transaction and at least oneparty from one RTE W. Such data entry may be performed by an operator ofthe CS [2] through a means such as a web-browser-based interface, asshown in FIG. 1 [25]: “User Web Client”), or by remotely loading valuesinto the database tables through a database loader utility, or by usinga programmatic interface for performing remote database updates.Subsequent modifications may be performed in a like manner.

An authorized user may log into the inventive system and, upon beinggranted access thereby, may view data and log records related to hisaccount and edit his/her Profile and select from among predefinedCommunication Sequence Patterns. (If a superuser, s/he may view and editthe accounts and Profiles, Rules Sets, and Communication SequencePatterns of others within his/her proscribed range of access.)

In practice, parties having a potential interest in transactions whichmay be processed by the inventive system will tend to updated their ownProfiles as may regard their preferred communication devices. Sequencesof contact thereon, preferred language, and related Roles, for varioustransaction types which the operator or other user of the inventivesystem may provide to them, per the specific embodiment of the inventivesystem. The operator or other user of the inventive system will tend tomanage and update all other information, particularly rule- andmessage-oriented information.

Although the present invention has been described in relation toparticular embodiments thereof, many other variations and modificationsand other uses will become apparent to those skilled in the art.Therefore, the present invention is not limited by the specificdisclosure herein.

1-110. (canceled)
 111. A computer-implemented system for providing atransaction, the system comprising: a transaction processing moduleconfigured to process a transaction and to communicate via a firstcommunications link and one or more second communications links, whereinthe transaction processing module: receives, via the firstcommunications link, incoming information associated with a transaction;identifies at least one party associated with the transaction, whereinthe at least one party is authorized to verify the transaction and is anon-merchant with regards to the transaction; transmits, via the one ormore second communications links, a verification request to the at leastone party to verify the transaction, wherein the one or more secondcommunications links are different from the first communications link;recognizes an occurrence of an event; determines authenticity of thetransaction based on the recognition of the occurrence of the event; andcontinues processing the transaction initiated over the firstcommunications link.